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29, 2000. 

Background of the Invention 

Field of the Invention 

10 The present invention relates to the modeling of a hospital; more specifically, 

the invention relates to modeling the flow of patients through hospital units. 
Description of the Related Art 

Care of patients in a hospital is of great concern to all - doctors, nurses, patient 
care staff, the patient and the patient's family as well as hospital administrators. 
5 Increased care can lead to increased chances for better recovery for the patient. 
However, there are limits on the care a hospital can provide to a patient, given given its 
resources: availability of care providers, availability of equipment, availability of beds, 
etc. 

Among these concerns is the efficient moving of patients through the various 
!0 hospital units. Often a patient is moved from one care unit to another care unit 
depending upon the condition of the patient and the care required. Sometimes, 
however, the care unit the patient is to be moved to is full and so that the patient cannot 
be moved and subsequently cannot receive the exact healthcare required. Conversely, 
sometimes patients must be moved from an optimal care unit to have access to special 
25 monitors located in another care unit. Such delays or unnecessary stays in inappropriate 
care areas may delay recovery and discharge and lead to unnecessary costs and sub- 
optimal care. These problems are complicated by the limitations, including, but not 
limited to, of numbers of beds, number of monitored beds, staff and equipment in a 
hospital. 

30 Summary of the Invention 



In accordance with one embodiment of the present invention, a method of 
modeling patient flow through a hospital is disclosed. Data regarding hospital statistics 
(such as length of stay, etc.) is collected. An hourly cost is assigned to each care unit 
for each patient. Based upon the collected data, a model is built. The model can 
5 simulate flow of patents through the hospital. 

In accordance with another embodiment of the present invention, a method of 
determining and/or predicting bottlenecks in a hospital is disclosed. 

In accordance with a third embodiment of the present invention, a method of 
recommending hospital resource changes (such as patient monitoring equipment) to 
10 improve patient flow through a hospital is disclosed. 

In accordance with a fourth embodiment of the present invention, a method of 
collecting hospital information utilization based upon real-time patient and hospital 
information is disclosed. 

For purposes of summarizing the invention, certain aspects, advantages and 
15 novel features of the invention have been described herein. It is to be understood that 

not necessarily all such advantages may be achieved in accordance with any particular 
embodiment of the invention. Thus, the invention may be embodied or carried out in a 
manner that achieves or optimizes one advantage or group of advantages as taught 
herein without necessarily achieving other advantages as may be taught or suggested 
20 herein. 

These and other embodiments of the present invention will also become readily 
apparent to those skilled in the art from the following detailed description of the 
embodiments having reference to the attached figures, the invention not being limited to 
any particular embodiment(s) disclosed. 
25 Brief Description of the Drawings 

These and other features and advantages of the invention will now be described 
with reference to the drawings of certain preferred embodiments, which are intended to 
illustrate and not to limit the invention, and in which: 

FIGURE 1 is a flow chart of the modeling of patient flow in accordance with an 
30 embodiment of the present invention. 
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FIGURE 2A and 2B depict a clinical assessment and hospital process evaluation 
data input form. 

FIGURES 3 A-H are data collection charts used to determine hospital statistics in 
accordance with an embodiment of the present invention. 
5 FIGURE 4 is a simple hospital care unit flow chart. 

FIGURE 5 is a snap shot of a patient flow as viewed by care units produced by a 
patient flow modeling program in accordance with an embodiment of the present 
invention. 

FIGURE 6 is a snap shot of a real-time status report including resource statistics 
10 of patient flow and resource utilization of a patient flow modeling program in 
accordance with an embodiment of the present invention. 
FIGURE 7 is a patient monitoring census report. 

FIGURE 8A-C are cost analysis charts produced by the patient flow modeling 
program in accordance with an embodiment of the present invention. 
15 FIGURE 9A-C are resource utilization charts produced by the patient flow 

modeling program in accordance with an embodiment of the present invention. 

FIGURE 10A-B are resource statistic charts produced by the patient flow 
modeling program in accordance with an embodiment of the present invention. 

FIGURE 1 1 and 12 are EXCEL spreadsheet snap-shots used in modeling patient 
20 flow in accordance with an embodiment of the present invention. 

Detailed Description of the Preferred Embodiment 
The system and method will now be described with reference to the drawings. 
These details are set forth in order to illustrate, and not to limit, the invention. The 
25 scope of the invention is defined only by the appended claims. 

FIGURE 1 is a flow chart illustrating the general methods that are in accordance 
with various preferred embodiments of the present invention, including, but not limited 
to, modeling the patient flow through a hospital, predicting bottlenecks in patient flow 
through a hospital, and generating cost/resource analysis figures for a hospital 
30 The modeling of patient flow can be done by a hospital to evaluate its 

performance or by a seller of patient monitoring equipment in order to show the cost 



-3- 



savings such equipment could realize. Thus, the steps in FIGURE 1 are preferably done 
by a business entity that provides services to hospitals, or by a business entity that sells 
a monitoring system product that allows hospitals to move patients from care unit to 
care unit. 

5 The first step in the method, step A, is to collect data from the hospital. The 

data shall cover each and every unit in the hospital, including but not limited to: 
admitting, the Emergency Department (ED), Intensive Care Unit (ICU), Intermediate 
Care or Step-down Units, the Catherization Lab, the Operating Rooms (OR), and post 
surgical recovery units, the cardiac unit, the Renal care unit, the Cardiovascular ICU, 
10 the Cardiac ICU, the Medical ICU, the Heart Center/EKG/Vascular Lab, other special 
care units, Surgery, telemetry, general med-surgical units, and discharge. Depending on 
the hospital, there may be more or less care units and/or these care units may be given 
different names. 

The data to be collected from each unit includes statistics and other factual 

15 information about the hospital. The data (statistics) can include, but is not limited to, 

inventory of beds, inventory of monitored beds, average occupancy (during a day, week, 
month), average patient length of stay, number of nurses, number and type of 
monitoring equipment available, average nurse-to-patient ratios, number of other 
healthcare specialists, the patient acuity range, the number of patient transports to and 

20 from the unit, the care unit admission sources from which patients come (and how 
often), admissions and the care unit or other location to which patients are 
transferred/discharged (and how often). Next, data regarding the hospital on a macro 
level is collected. This information can include, but is not limited to, average number 
and source of admittance admissions, frequency of admittance, the average number of 

25 discharges, frequency of discharge, average overall stay in hospital, average number of 

ED visits with percentage admitted, average occupancy and overall length of stay 
(LOS), and average cost per admission. 

A preferred chart used to gather data about the clinical assessment and hospital 
process evaluation is shown in FIGURES 2A-B. Additionally, FIGURES 3A-I show 

30 various initial assessment forms that can also be used to gather information regarding 
other hospital statistics and information. These forms can be created in Microsoft® 
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Excel™ and appropriately linked together in a spreadsheet and form part of a model for 
patient flow, as will be described below. 

The various data can be collected by interviewing hospital staff and/or by 
extracting information from hospital records or databases. The information collected 

5 may reflect data from one day or longer, but preferably 90 days to ensure the data 
accurately reflects the operation of the hospital In some cases, where hospitals 
experience significant seasonal variations in census, it is necessary to collect admissions 
and other data over a longer period and model different time periods. Additionally, the 
information can be collected automatically by a computer program as described in fuller 

10 detail below. 

Once step A is completed, an hourly cost is assigned for each unit per patient in 
step B. This number can be generated by a variety of methods. The cost assigned can 
depend on a variety of resources, including but not limited to doctor time, nurse time, 
staffing, drugs, IVs, and other equipment costs. Such assignments of costs are well 

15 known in the art. Such cost data can be extracted from Medicare data, for example by 
data mining and benchmarking companies such as Solucient and Ingenix. For instance, 
Solucient is an Internet-based tool that provides the strategic performance information 
hospitals and health systems may need. SoleSource.net delivers analysis of hospital and 
physician performance based on a wealth of clinical and financial indicators, and saves 

20 time by calculating the variance to external benchmark comparisons. Alternatively, 

many hospitals have internal cost accounting systems that provide average cost per day 
by different care units. 

Next, in step C, a model is built in accordance with this information. The model 
is preferably generated by a specialist but could alternatively be generated automatically 

25 using a model generation program. The modeling can be achieved with a variety of 

modeling programs that are well known in the art. Examples are AZTEC, Visual Basic, 
Optima by Micrografx, Inc., or Igraphics, Inc. Modeling and simulations have been 
previously discussed in United States Patent 5,617,321 to Frizelle, et al. and United 
States Patent 6,154,731 Monks et al., both of which are incorporated herein by 

30 reference. 
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In one embodiment of the present invention for step B, one first builds a multi- 
level model of the key hospital care units. These include as a minimum the ED, OR and 
interventional cath labs, intensive care units, intermediated care units and general 
medical surgical units. Each of the levels may be expanded to include more specialized 
5 units. For example, the intensive care unit could have a medical ICU, a surgical ICU 

and coronary care unit. Each unit is then described in terms of numbers of monitored 
beds and other resources and average length of stay (LOS). Beginning at the admission 
source point, one assigns the percentage of patients that go to each care unit. Each care 
unit, in turn, is further described by the percentage of patients going to other care units. 
10 The end point is discharge. Finally one begins the simulation at the admission start 
point by describing the number of patients to be admitted per unit time and the length of 
time to run the model. The model then will generate patient flow according to each unit 
^; in a path and that unit's assigned characteristics. 

ill In one embodiment of the present invention, and referring to FIGURE 1, a 

s fx;" 

\*k 1 5 computer, or any microprocessor or processor can be utilized to perform the steps. Such 

Jl devices may permits access to the Internet or an Intranet, and include terminal devices, 

^ such as personal computers, workstations, servers, clients, mini computers, main-frame 

O computers, laptop computers, a network of individual computers, mobile computers, 

m palm-top computers, hand-held computers, set top boxes for a TV, interactive 

^ 20 televisions, interactive kiosks, personal digital assistants, interactive wireless 

communications devices, mobile browsers, or a combination thereof The computer 
may further possess input devices such as a keyboard, mouse, touchpad, joystick, pen- 
input-pad, and output devices such as a computer screen and a speaker. 

These computers may be uni-processor or multi-processor machines. 
25 Additionally, these computers include an addressable storage medium or computer 

accessible medium, such as random access memory (RAM), an electronically erasable 
programmable read-only memory (EEPROM), programmable read-only memory 
(PROM), erasable programmable read-only memory (EPROM), hard disks, floppy 
disks, laser disk players, digital video devices, compact disks, video tapes, audio tapes, 
30 magnetic recording tracks, electronic networks, and other techniques to transmit or store 

electronic content such as, by way of example, programs and data. In one embodiment, 
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the computers are equipped with a network communication device such a network 
interface card, a modem, or other network connection device suitable for connecting to 
the communication medium. Furthermore, the computers execute an appropriate 
operating system such as Linux, Unix, Microsoft® Windows® 95, Microsoft® 

5 Windows® 98, Microsoft® Windows® NT, Apple® MacOS®, or IBM® OS/2®. As is 

conventional, the appropriate operating system includes a communications protocol 
implementation which handles all incoming and outgoing message traffic passed over 
any communications lines. In other embodiments, while the operating system may 
differ depending on the type of computer, the operating system will continue to provide 

10 the appropriate communications protocols necessary to establish communication links 

with any monitoring devices or other hospital computers. 

The computers may advantageously contain program logic, or other substrate 
configuration representing data and instructions, which cause the computer to operate in 
a specific and predefined manner as described herein. In one embodiment, the program 

15 logic may advantageously be implemented as one or more object frameworks. These 

modules may advantageously be configured to reside on the addressable storage medium 
and configured to execute on one or more processors. The modules include, but are not 
limited to, software or hardware components which perform certain tasks. Thus, a module 
may include, by way of example, components, such as, software components, object- 

20 oriented software components, class components and task components, processes, 
functions, attributes, procedures, subroutines, segments of program code, drivers, 
firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and 
variables. 

The depicted steps in Figure 1 and in later figures may be implemented in 
25 modules and those modules may advantageously communicate with each other and 

other components comprising the respective computers through mechanisms such as, by 
way of example, interprocess communication, remote procedure call, distributed object 
interfaces, and other various program interfaces. Furthermore, the functionality 
provided for in the components, modules, and databases may be combined into fewer 
30 components, modules, or databases or further separated into additional components, 
modules, or databases. Additionally, the components, modules, and databases may 
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advantageously be implemented to execute on one or more computers. In another 
embodiment, some of the components, modules, and databases may be implemented to 
execute on one or more computers, internal or external to the hospital. 

As a sub-step, the information can be put into a spread sheet program, such as 
Microsoft® Excel™, and a model created therein. This sub-step is useful to check the 
overall results of the model compared to actual parameters. For example the sub-step 
allows one to verify that the general model will yield a realistic occupancy rate and 
length of stay. This is easier to analyze and debug than working with the complex 
simulation model itself. FIGURE 1 1 and 12 are EXCEL spreadsheet snap-shots used in 
modeling patient flow. 

For example, a basic map of flow of patients through a hospital is illustrated in 
FIGURE 4. Each care unit is illustrated as a block and lines connect each block to 
indicate the possible movement of patients from one care unit to another care unit. Each 
care unit or block is assigned the characteristics determined by the data previously 
collected. Additionally, the hospital, as a layer on top of the care unit layer, is assigned 
its characteristics as determined by the data previously collected. For instance, each 
unit is assigned an average patient length of stay, number of beds, number of healthcare 
staff, etc. Once the model has been built, it has enough information to reflect the rules 
of operation that determine how patients move through a hospital. Given this 
information, the model can predict future movements of a patient. Moreover, the model 
can determine the effect of a new patient admitted to the hospital. The model can also 
identify or predict bottlenecks in patient flow. Additionally, the model can show the 
financial impact of bottleneck and near bottleneck situations. This is accomplished by 
calculating the cost to the hospital or individual by keeping people in one care unit, 
when they should be transferred to another care unit, which may be able to tend to 
additional patients, due to issues of capacity or staff 

After the model is built, there are at least two possible simulations that can be 
run; (1) hypothetical simulation of the hospital and (2) real-time analysis. These two 
paths are illustrated in FIG. 1 by steps D and F, respectfully. In each simulation, 
predictions of bottlenecks are possible. 



As indicated in step D, a simulation can be run, based upon the average hospital 
data, including but not limited to, the number of hospital admissions, where they are 
admitted to, to determine the effect of new admittees to a hospital. The initial settings 
for the model can either be: no patients in the hospital at all or any number of patients 

5 in any care unit. Then the simulation can be run. The user can either choose the 
number of patients and the care units they are assigned to patients, or the model can 
determine this. As more patients enter into the model and the model proliferates. The 
model will update hospital admissions, discharges, and transfers between care units. 
Over time and depending upon the characteristics of the hospital, the model can predict 

10 where bottlenecks will occur. A bottleneck is preferably defined as a situation where a 
care unit is full to capacity and other patients seek transfer to that care unit. Thus, the 
model will illustrate where the bottlenecks are and the updated average wait times 
patients have to endure before moving to another care unit. When a bottleneck situation 
occurs, a healthcare providers seek to know who can be moved and where and usually 

15 based, in part, on efficiency. This decision can be based upon the health status of the 
patient, the general care ward, lab results, and other metrics - all of which can be 
implemented into an expert system and implemented into the modeling program. 
However, if patients need to be in a certain care unit and cannot be moved or 
transferred, other patients cannot come into that care unit. Nonetheless, if a patient's 

20 bed, in one care unit, has equipment that allows for the communication of patient 
information to the nursing or other healthcare staff of another care unit, then the same 
supervision of patient information is capable no matter where the patient physically 
resides. Thus, care units are not locked into any brand of monitoring equipment since 
all equipment could, with appropriate systems (like PatientNet™, OpenNet®, and 

25 Sitelink®, all by Vitalcom, Inc.), communicate with all care units' patient information 

monitoring stations. 

The PatientNet™ system is an open, real-time communication network that 
gives caregivers instant access to vital patient information. PatientNefs™ advanced 
wireless infrastructure brings patients online and sends time-critical patient information 
30 to a "Mission Control M -like technology center in your hospital. There, certified 
technicians watch monitors 24/7, providing consistent monitoring quality to patients 
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across the enterprise. Technicians instantly notify caregivers via an integrated paging 
system if a critical event occurs. Patient information is also simultaneously available to 
caregivers at viewing stations throughout the healthcare system. With the PatientNet™ 
wireless infrastructure: (1) any bed can become a monitored bed; (2) all patients receive 

5 the same quality of monitoring care; (3) patient flow bottlenecks can be eliminated; (4) 
transfers are substantially reduced; and (5) efficiency is increased across the enterprise. 

OpenNet® is the core wireless technology that makes the PatientNet™ system 
open and unique. Traditional monitoring networks are closed - requiring hospitals to 
purchase monitor devices from one manufacturer in order to display the information on 

10 their network. OpenNet® technology enables other manufacturers' medical devices to 
be integrated into the PatientNet™ system, helping to leverage existing investments in 
capital equipment and making all monitored information available on a single system, 
which creates patient care efficiencies. 

SiteLink® expands the reach of a tertiary center's real-time monitoring services 

15 to other facilities within the organization, to affiliate healthcare facilities across town, 
even to remote facilities hundreds of miles away. SiteLink® can enhance operational 
processes, support a consistent standard of care and enable enterprise-wide cost savings. 

SiteLink® enables patients at remote or affiliate organizations to be monitored 
by a "Mission Control M -like technology center located at the tertiary facility. SiteLink® 

20 uses wide area network technology: patient waveforms and other vital signs are 
transmitted in real time to PatientNet™ Mission Control. Simultaneously, the data is 
available for review by caregivers throughout the enterprise, including at the remote or 
affiliate site. 

Additionally, as in step F of FIG. 1, the model, or a human operator of the 
25 model, can suggest what types of additional resources are needed in the hospital and 

where those resources should be located. This prediction can be based upon the 
identification of bottlenecks or near bottleneck situations or inadequate resource 
utilization or cost analysis. Once the changes are made and the model rebuilt, the 
simulation can be re-run. The updated model can illustrate how effective the changes 
30 are and if any other changes are needed. A side by side display of both simulations can 
run. Moreover, by illustrating the pitfalls and potential bottlenecks in the hospital 
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system, a provider of services that changes any bed in any unit into a multipurpose bed 
capable of receiving services traditionally associated with another care unit, can more 
easily sell their product. For example, OpenNet®, from Vitalcom, Inc., uses wireless 
technology to capture patient information from any manufacturers devices located 

5 throughout the healthcare enterprise. In this manner, patient information is distributed 

in real-time to wherever it is needed, including, but not limited to, nursing stations, 
physician offices or remote locations. With OpenNet® technology or other such 
technology, any bed can become a monitored bed, allowing a person in one care unit to 
be monitored by the staff of another care unit. Therefore, OpenNet® can aid in 

10 decreasing costly patient flow problems by reducing bottlenecks by allowing hospitals 
the ability to transfer patients to another care unit and still monitor them in the 
transferor care unit as if they were in that care unit. In this way, beds can open up to 
those that need to be transferred to that care unit. Thus, the flow connecting each care 
unit to each other is given greater flexibility, and the flow of patients as a whole is 

1 5 increased. Basically, the hospital becomes more efficient. Alternatively, any bed in one 

care unit can be monitored by another care unit's staff and thus there would be no need 
to transfer that patient unless necessary, or monitors (that are not traditionally kept in 
one care unit) can be imported from another care unit and connected to the patient's 
equipment. 

20 Alternatively, as in step F of FIG. 1, the model can be populated with real-time 

data from the hospital. This data can be acquired from a hospital database such as an 
ADTS (Admission Discharge Transmission System), or a point of care system, or a 
patient locator system. 

Generally, patient locator systems monitor the location of patients within a 

25 hospital by various wireless techniques. Any of a variety of object/patient location- 

tracking methods may be used within the system to track the locations of the devices or 
patients. One such technique is described in U.S. provisional appl. no. 60/193,655, filed 
March 31, 2000, the disclosure of which is hereby incorporated by reference. With this 
method, chirpers are positioned throughout the regions of the medical facility in which 

30 location-tracking functionality is desired. The chirpers periodically transmit unique ID 

signals at predetermined signal strengths. These signals are received by nearby 
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location-tracking devices that are attached to the objects to be tracked. The location- 
tracking devices retransmit the ID signals they receive (preferably in an ISM band) 
along with a corresponding received signal strength indicator (RSSI). The retransmitted 
ID and RSSI data is received by nearby location-tracking modules, which forward such 
data to a location tracking server. The location tracking server uses the combination of 
chirper IDs and RSSI values it receives from a given location tracking device at a given 
point in time to determine the device's current location. Other location tracking 
methods and architectures that may be used include those described in the U.S. Patent 
No. 5,944,659, assigned to VitalCom Inc., the disclosure of which is hereby 
incorporated by reference. Also, U.S. provisional application 60/193,650, filed March 
31, 2000, the disclosure of which is hereby incorporated by reference, discloses another 
patient locator method. GPS-based system may also be used for this purpose. 
Regardless of the particular tracking method used, the near-real time location 
information for the tracked objects is preferably stored by the location-tracking server 
and is made available on the network. 

Furthermore, the model could be automatically built or programmed based upon 
collected data. For instance, once data spanning several days or weeks is entered into 
the model or collected by the model after hospital observation, the model can generate 
all the statistics and information regarding transfers etc. needed to build the model. 

After the real-time data is inputted into the model, the progress of patients can 
be tracked, much like in an animated manner such that the throughput of patients and 
cost accrued by each unit is visible. In this embodiment, alarms can be set up to alert 
hospital staff of impending bottleneck situations. Therefore, patients could be moved 
around between units before the units actually became overloaded. 

Alternatively, the model can be populated with real-time hospital data from the 
last days, or months or years. Then, the model can replay the events in chronological 
order and identify bottlenecks that occurred in the past, previous resource under- 
utilization and other potential faults that occurred in the hospital flow system. 

Additionally, affiliated hospitals can be linked together with remote monitoring 
systems such as SiteLink® from Vitalcom, Inc. With such technology, the patient 
information is available for review by caregivers throughout the enterprise, including at 
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the remote or affiliate site. With SiteLink®, caregivers can check a patient's real-time 
status at any location along the network. Additionally, PatientNet® integrates patient 
data from any manufacturers' device into the SiteLink® network. Thus, the model can 
be used to analyze the hospitals in total. In this way, affiliated hospitals can better 
determine how to response to demands on its collective resources. Such capabilities 
could be utilized to transfer patients between the affiliated hospitals in order to better 
utilize the hospitals' collective resources. 

Alternatively, the real-time model can be supplemented with hypothetical 
additional admissions and the effect additional admissions would have on the hospital 
can be predicted. 

Regardless of whether the model is run using real-time, past, or hypothetical 
data, various status reports can be generated by the modeling program. FIGURE 5 is a 
snap shot of the patient flow output as viewed by care unit of a patient flow modeling 
program in accordance with an embodiment of the present invention. In FIG. 5, each 
care unit is assigned a percentage that reflects how full the care unit is. Other statistics, 
such as resource utilization or average wait time in care unit, etc. can be displayed as 
well. 

FIGURE 6 is a snap shot of a real-time status report including resource statistics 
of patient flow and resource utilization of a patient flow modeling program in 
accordance with an embodiment of the present invention. FIG. 6 illustrates a summary 
of the current and recent statistics for each care unit and the hospital as a whole. The 
overflow status of each care unit is displayed, including the current overflow, projected 
overflow based upon the model and suggested course of actions. The suggested course 
of action can be to add beds or other healthcare resources. The model can also suggest 
which patients to move based upon their acuity (for example, by using the Van Slyke 
system) and other factors, which are well known in the art. The model can also track 
the resource utilization of staff including nurses, doctors and other healthcare staff. This 
can be accomplished by tracking nurses responses to patient care pages. 

FIGURE 7 is a patient monitoring census report. FIG. 7 illustrates the statistics 
for each patient in the hospital. The model can use these statistics and information to 
predict when to discharge or transfer a patient to another care unit. 
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FIGURE 8A-C are cost analysis charts produced by the patient flow modeling 
program in accordance with an embodiment of the present invention. FIG. 8A-C 
display the various costs associated with a patient stay in a hospital and specifically, in a 
care unit. 

FIGURE 9A-C are resource utilization charts produced by the patient flow 
modeling program in accordance with an embodiment of the present invention. 

FIGURE 10A-B are resource statistic charts produced by the patient flow 
modeling program in accordance with an embodiment of the present invention. 

Although this invention has been disclosed in the context of certain preferred 
embodiments and examples, it will be understood by those skilled in the art that the 
present invention extends beyond the specifically disclosed embodiments to other 
alternative embodiments and/or uses of the invention and obvious modifications and 
equivalents thereof. Further, the various features of this invention can be used alone, or 
in combination with other features of this invention other than as expressly described 
above. 

Of course, it is to be understood that not necessarily all such objects or advantages 
may be achieved in accordance with any particular embodiment of the invention. Thus, 
for example, those skilled in the art will recognize that the invention may be embodied or 
carried out in a manner that achieves or optimizes one advantage or group of advantages 
as taught herein without necessarily achieving other objects or advantages as may be 
taught or suggested herein. 

Furthermore, the skilled artisan will recognize the interchangeability of various 
features from different embodiments. Similarly, the various databases and conversion 
modules, as well as other known equivalents for each such feature, can be mixed and 
matched by one of ordinary skill in this art to construct order fulfillment systems in 
accordance with principles of the present invention. 

Thus, it is intended that the scope of the present invention herein disclosed 
should not be limited by the particular disclosed embodiments described above, but 
should be determined only by a fair reading of the claims that follow. 
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